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The mission architecture of the Gamma-ray Large Area Space Telescope (GLAST) 
requires a sophisticated ground system component for scheduling the downlink of science 
data. Contacts between the GLAST satellite and the Tracking and Data Relay Satellite 
System (TDRSS) are restricted by the limited field-of-view of the science data downlink 
antenna. In addition, contacts must be scheduled when permitted by the satellite’s complex 
and non-repeating attitude profile. Complicating the matter further, the long lead-time 
required to schedule TDRSS services, combined with the short duration of the downlink 
contact opportunities, mandates accurate GLAST orbit and attitude modeling. These 
circumstances require the development of a scheduling system that is capable of predictively 
and accurately modeling not only the orbital position of GLAST but also its attitude. This 
paper details the methods used in the design of a Commercial Off The Shelf (COTS)-based 
attitude-dependent TDRSS contact scheduling system that meets the unique scheduling 
requirements of the GLAST mission, and it suggests a COTS-based scheduling approach to 
support future missions. The scheduling system applies filtering and smoothing algorithms 
to telemetered GPS data to produce high-accuracy predictive GLAST orbit ephemerides. 
Next, bus pointing commands from the GLAST Science Support Center are used to model 
the complexities of the two dynamic science gathering attitude modes. Attitude-dependent 
view periods are then generated between GLAST and each of the supporting TDRSs. 
Numerous scheduling constraints are then applied to account for various mission specific 
resource limitations. Next, an optimization engine is used to produce an optimized TDRSS 
contact schedule request which is sent to TDRSS scheduling for confirmation. Lastly, the 
confirmed TDRSS contact schedule is rectified with an updated ephemeris and adjusted bus 
pointing commands to produce a final science downlink contact schedule. 


I. Overview of Scheduling Problem 

T he Gamma-ray Large Area Space Telescope (GLAST) is a multinational project funded by the National 
Aeronautics and Space Administration (NASA), the United States Department of Energy (DOE), and by 
government agencies in Italy, France, Japan, and Sweden. The 10-year mission, scheduled to launch in August 2007, 
is to survey the gamma-ray sources of the celestial sphere and provide the ability to dwell on specific gamma-ray 
targets of interest. The satellite bus, manufactured by General Dynamics, carries two science instruments, the Large 
Area Telescope (LAT) and the Gamma-ray Burst Monitor (GBM). The LAT is a joint project between NASA and 
the DOE. The LAT is constructed by Stanford University, the Stanford Linear Accelerator Center, the University of 
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California, Santa Cruz, the Naval Research Laboratory, NASA Goddard Space Flight Center (GSFC), and the 
international partners. The GBM is a joint project between Marshall Space Flight Center, the University of Alabama, 
and the Max-Planck Institute in Germany. Goldbelt Orca, LLC anti Omitron, Inc. are teamed to provide the GLAST 
Mission Operations Center (MOC) and flight operations services. The MOC is located at the NASA GSFC in 
Greenbelt, MD. 1 



Figure 1-1 GLAST Configuration 


A. Attitude Effect on TDRS Contacts 

GLAST science data is downlinked through a 40 Mbps Ku-band radio frequency (RF) link using the Space 
Network.. The Ku-band transmitter uses a narrow beam antenna mounted on a gimbal providing an effective field-of- 
view of approximately 2x steradians, centered on the — z side of the observatory body frame of reference. Science 
needs are met by controlling the orientation of the LAT in time. The boresight of the LAT is fixed to the body frame 
and is aligned with the +z body -axis. Due to these circumstances, the times when the Ku-band antenna has constraint- 
free line-of-sight access to each Tracking and Data Relay Satellite (TDRS) is dependent not only on the relative 
orbital positions of GLAST and each TDRS, but also on the attitude of the GLAST observatory. 

GLAST science needs are met by commanding the observatory into either of the two science-gathering attitude 
modes: Sky Survey mode and Inertial Point mode. Both attitude modes are dynamic and complex. For each mode, 
the motion of the observatory in time is defined by a series of flight parameters, each of which may be 
independently changed. This produces a large number of possible attitude profile configurations. The configuration 
and use of these modes is expected to be non-repeating over the life of the mission and predictable only over a short 
duration. The GLAST project science center provides the MOC with a preliminary timeline of observatory pointing 
profile commands 19 days in advance to allow TDRS scheduling. In addition to this predictable attitude, there are 
two circumstances which could cause the observatory to deviate from its planned attitude profile. First, a Target of 
Opportunity (ToO) is an event where the science center instructs the MOC to command the observatory to Inertial 
Point mode on short notice to observe a special celestial event that was not anticipated during the normal science 
planning period. Secondly, during an autonomous re-point (AR), the observatory may autonomously re-orient itself 
without warning in response to a detected gamma-ray burst of significance. 

B. TDRS Scheduling Overview 

With the attitude-dependent contact scheduling constraint and a complicated attitude profile, TDRS Ku-band 
single access return link contacts must be scheduled to ensure that all science data is recovered from the Solid State 
Recorder (SSR) in a timely manner. Complicating the problem further, the GLAST ground system has a requirement 
that the science-driven attitude profile must not be interrupted to downlink the data. With the exception of the times 
when the observatory passes through the South Atlantic Anomaly (SAA), science gathering is a full-time operation. 
As a result, there is no practical time available to re-orient the observatory to achieve a favorable attitude for a 
TDRS contact. The MOC must therefore schedule contacts during times when the science-driven attitude profile 
offers serendipitous line-of-sight access between the GLAST Ku-band antenna and a TDRS. 

The boresight of the effective field-of-view of the GLAST Ku-band antenna and its gimbal is oriented opposite 
of the boresight of the primary instrument. Because GLAST is a gamma-ray observatory, both science gathering 
attitude modes maintain the orientation of the primary instrument away from the Earth. This results in the boresight 
of the Ku-band antenna’s effective field-of-view being always within the Earth disk. GLAST will be launched into a 
circular 565 km orbit inclined at 28.5°. This attitude and orbit vastly reduces the amount of line-of-sight access time 
that the Ku-band antenna has with the geostationary TDRSs. In the principal science gathering mode. Sky Survey, 
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contact times are between eight and twelve minutes in duration. As a result, a relatively large number of these short 
duration contacts must be scheduled each day to ensure adequate science data recovery. 

The GLAST MOC has the responsibility of obtaining adequate TDRS contacts. Nominal TDRS contact 
scheduling is done on a weekly basis and requires between 14 and 21 days of lead-time. GLAST command loads are 
also performed on a weekly basis; however, for operational reasons, the GLAST command load week does not align 
with the TDRS schedule week. This increases the TDRS contact scheduling lead-time to between 18 and 25 days. 
The long lead time along with the large number of attitude-dependent, short-duration contacts necessitates a 
dedicated contact scheduling system with a high degree of orbit and attitude prediction accuracy to allow TDRS 
contacts be accurately scheduled. The scheduling complexity and volume of contacts needed also mandates that this 
system be highly automated to reduce burden on the flight operations team and to reduce the risks associated with 
manually-performed complex tasks. 

II. FDS Overview 

C. Principal Functions of the FDS 

To meet the scheduling needs of the GLAST mission, the GSFC Flight Dynamics Facility (FDF), Goldbelt Orca 
LLC, and Omitron, Inc., have teamed to develop a TDRSS contact scheduling system referred to hereafter as the 
Flight Dynamics System (FDS). The principal functions of this system include: 

• Modeling the orbital positions of GLAST and TDRSS 

• Modeling the attitude of GLAST 

• Producing TDRS contact requests, 

• Determining final contact schedules, 

• Providing the ability to schedule late contacts using TDRSS Unscheduled Time 

D. Custom and COTS Software K 

The FDS system is composed of a combination of Commercial-Off-The-Shelf (COTS) products and^custom 
developed code. The majority of the computations are performed by a COTS satellite analysis software suite. The 
suite consists of Satellite Tool Kit (STK) modules provided by Analytical Graphics, Inc. The module#nclude 
STK/Pro, STK/Connect, STK/OD Tool Kit, STK/Attitude, STK/Chains, and STK/Scheduldr. The STK/Advanced 
VO iSnodule is also used for 
visualization purposes, but is not 
required for the FDS to function. 

Automation control of the COTS 
analysis software, as well as all of the 
computations performed externally, are 
accomplished using custom code 
written in ActiveState’s ActivePerl. In 
addition, the Perl scripts are initiated 
using a graphical user interface written 
in Microsoft’s Visual Basic. 

E. FDS Interfaces 

The FDS interfaces with several 
entities, both internal and external to 
the MOC. The FDS receives Global 
Positioning System (GPS) position 
data from the MOC’s telemetry and 
command system. TDRS ephemeris 
files are provided by NASA/FDF. 

Preliminary and final bus pointing 
commands are received from the 

GLAST project science center. TDRSS Figure ELI FDS Interfaces 
schedule requests and confirmations 
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are interchanged with the Network Control Center Data System (NCCDS) via the Space Network Web Services 
Interface (SWSI) system. Finally, the FDS provides orbit events and schedule information to the command load 
generation tool and, for informational purposes only, to external ground system elements (not shown). 

HL Orbit Determination 

F. Overview of GLAST Orbit Determination 

The GLAST Ku-band transmitter can support orbit determination via differenced one-way Doppler ranging. 
However, this method would require ongoing, customized support from NASA flight dynamics assets. To reduce 
operations cost and simplify external interfaces, the MOC uses the dual onboard GPS receivers as the sole 
operational orbit-determination data source. (If both GPS receivers should fail, orbit determination can continue 
using NORAD Two-Line Element (TLE) sets. Orbit determination precision would suffer in this mode. However, 
the Swift mission experience demonstrates that a LEO astrophysics observatory can be navigated using TLE sets 
alone.) 

The GPS receivers nominally provide spacecraft position and velocity measurements at 1 -second intervals. This 
orbit-state telemetry is recorded on the SSR, then periodically transmitted to the MOC during TDRS Ku-band 
contacts. After the MOC’s telemetry and command system processes this telemetry (time-ordered, duplicate- 
removed, ASCII formatted, etc.), the FDS uses it to generate mission-planning products. To track current TDRS 
spacecraft positions for TDRS contacts, the GLAST spacecraft stores and propagates simplified ephemerides for 
active TDRS vehicles. These ephemerides are maintained by the FOT, based upon standard TDRS ephemeris data 
from NASA FDF. These standard TDRS ephemerides also drive the FDS’s own TDRS position prediction. 

The GLAST mission requires predicted orbit determination precision within 22 km after 7 days. This 
requirement is driven by the spacecraft’s need for accurate telemetry pass predictions and the payload’s need for 
accurate observational line-of-sight predictions. GLAST’s high-energy astrophysics payload also requires accurate 
South Atlantic Anomaly crossing times. Most importantly with respect to the current discussion, FDS scheduling of 
GLAST- to-TDRS Ku-band line-of-sight times cannot proceed without accurate position predictions for GLAST and 
all active TDRS satellites. 

G. Operational Data Flow 4 : 

The flight dynamics process begins with receipt of new GPS telemetry in the MOC. . After each contact, the 
MOC telemetry and command system processes any new GPS telemetry and writes it to text files. When a user 
executes the FDS ’s propagation task, the FDS ingests the- newest GPS position data. (At this writing, the 
propagation task is designed to concatenate the most recent 6 to 8 hours of GPS telemetry; the precise amount 
required for reliable orbit determination will be refined during prelaunch testing.) 

The FDS uses spacecraft position data only. The GPS velocity data is ignored for two reasons. Current on-orbit 
GPS receivers produce relatively “noisy,” imprecise velocity data, which would require independent smoothing 
steps for reliable propagation. 2 Also, the COTS software’s normal navigation input format uses position values only. 
The FDS filters the position telemetry for known quality indicators, rejecting any obviously bad telemetry values. It 
formats the data for use by the COTS software, then loads it into a COTS session. FDS executes COTS-proprietary 
filtering and smoothing algorithms to generate a smoothed orbital solution for the ingested time interval. FDS 
propagates this solution forward in time to generate predicted orbital ephemerides covering the next 30 days. 
Specifically, STK/OD propagates a state vector from the smoothed solution in its proprietary high-precision 
integrating propagator (HP OP). The orbital solution is created and stored as position/velocity ephemeris data, for 
later use by the other FDS components. 

Using GPS position data only, this method achieves accuracies of approximately 150 km over 30 days relative to 
definitive orbit data. (Software testing prior to this writing has used GLAST-like LEO missions as a surrogate GPS 
data source. Further accuracy assessments are ongoing.) In practice, orbit determination accuracy will depend upon 
selection and maintenance of key propagator parameters, such as space weather indices. The predictive propagation 
step uses fixed, averaged values of ballistic parameters such as cross-sectional area. Although the planned spacecraft 
attitude over the entire prediction period will be known, this data is not used to generate dynamic cross-sectional 
areas. Preliminary analysis early in the GLAST MOC development process indicated that atmospheric and space- 
weather variations would produce significantly larger orbit prediction uncertainties than variations in spacecraft 
attitude. Therefore, the orbit prediction process is treated as attitude-independent. 

The resulting ephemeris data is exported in STK format for use by the other FDS components. By separating the 
orbit-determination sequence from the other FDS functions, new GPS telemetry can be optionally processed without 
impacting other FDS products. Given an updated GLAST ephemeris, other FDS functions (not discussed in this 
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paper) can generate predicted times for TDRSS S-band and contingency ground station contact events. Because 
these contacts utilize the spacecraft’s omnidirectional S-band antennas, they are attitude-independent. Ku-band 
scheduling proceeds from the receipt of new preliminary bus pointing commands in the MOC, along with the GPS- 
derived predicted (jLAST ephemerides. 

IV. GLAST Attitude Modeling 

H. Overview of GLAST Attitude 

As stated above, GLAST has two attitude modes used to gather science data. They are Sky Survey mode and 
Inertial Point mode. Each mode is characterized by the algorithm used to orient LAT boresight, which is co-aligned 
with the +z body -axis of observatory. Once the +z body -axis orientation is defined, the remainder of the attitude 
definition, known as yaw steering, is controlled identically in both modes. Yaw steering simply controls the rotation 
about the +z body -axis such that the angle between the +x body -axis and the Sun vector is minimized. This method 
ensures that the Sun vector is always normal to the solar array rotational axis. 

I. Sky Survey Mode 

Sky Survey mode is the science gathering mode in which GLAST is expected to spend the majority of its 
operational life. It is characterized by aligning the +z body -axis with a rotational offset from the Zenith vector applied 
about the velocity vector. This rotational offset is known as the rocking angle. Sky Survey mode provides the 
flexibility to define the rocking angle as either a static value or as following a configurable 16-angle repeating 
profile where the rocking angle is interpolated linearly between consecutive angles. Throughout this motion, yaw 
steering is constantly performed to maintain the Sim vector on the body x-z plane on the +x side. To avoid high yaw 
steering rates as the body frame z-axis approaches the Sun vector, the orientation of the +z body -axis is altered in this 
vicinity. In a maneuver known as a sun-avoidance yaw flip, the +z body -axis follows a variable radius arc about the 
Sun or anti-Sun vector to ensure the total body rotation rate does not exceed the maximum observatory slew rate. 3 

2 . Inertial Point Mode f 

The second science gathering mode. Inertial Point mode, is expected to be used less often than Sk| y Survey 
mode. In this mode, the +z body -axis is simply fixed to a specific location in the celestial sphere to allow the LAT to 
dwell on a gamma-ray source. Inertial Point mode is also the mode the observatory will transition to during a ToO or 
AR event. To avoid pointing the LAT at the Earth as a gamma-ray source target becomes occulted, the +z body -axis 
traces-an Earth avoidance zone defined by a configurable number of degrees from the limb of die Earth. Limb 
tracing initiates when the target enters the avoidance zone and is performed at a constant body rate such that +z body - 
axis iiP again aligned with the target as it emerges from the avoidance zone. During long limb trace maneuvers, an 
additional +z body -axis radial offset from the Earth limb must be applied to prevent the Earth from blocking the view 
of the star trackers. The duration, profile, and magnitude of this additional offset are functions of the elevation of the 
target vector from the orbit plane. As with Sky Survey mode, yaw steering is performed throughout all aspects of 
Inertial Point mode to maintain the Sun vector on the x-z plane and on the +x side of the observatory body. 3 

I. Modeling Attitude Modes in COTS Software - 

3. Custom Vector Scripts '**" 

Because of the limited field-of-view of the Ku-band antenna and its positioning mechanism, the attitude of the 
observatory must be modeled to determine times when the antenna has line-of-sight access to a schedulable TDRS. 
The COTS analysis software has some built-in attitude modeling capabilities; however, those capabilities are not 
able to model the complexities of GLAST’s two science-gathering attitude modes. To alleviate this problem, the 
FDS creates custom code that integrates with the COTS software to precisely model each attitude mode. The COTS 
software provides plug-in points that allow users to develop custom scripts to define dynamically-varying vector 
definitions as functions of vectors provided by the COTS software. The FDS takes advantage of this ability by 
creating two different types of custom plug-in scripts, one defining a vector aligned with the orientation of the 
+z body -axis in Sky Survey mode and the other defining a vector aligned with the orientation of the +z body -axis in 
Inertial Point mode. Each of these scripts use the actual algorithms used by the GLAST flight software to control the 
observatory’s orientation. One of the features of the COTS software allows the attitude of a modeled satellite to be 
defined by aligning one axis of the body frame with one vector while constraining a second axis of the body frame 
to a second vector. When constraining, the modeled body frame is rotated about the alignment vector until the angle 
between the constraining axis and the constraining vector is minimized. Using this method to model GLAST’s 
attitude, the +z body -axis of the modeled satellite is aligned with a vector calculated by one of the custom scripts and 
the +x body -axis of the model is constrained to the calculated Sun vector. This approach simulates the orientation of 
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the +z bo d y -axis and the yaw steering algorithm to precisely model both of GLAST’s science gathering attitude 
modes. 

4. Command Interpretation 

The GLAST science center provides the MOC with a preliminary timeline of bus pointing commands 19 days 
prior to the TDRSS scheduling period. The FDS includes logic to ingest the time-ordered list of commands and 
interpret them in the same maimer as the GLAST observatory. The result of this process is a timetable of attitude 
mode segments and flight parameter values for the scheduling period. For each attitude segment, the FDS generates 
a custom code plug-in script using a script template corresponding to the associated science gathering mode. As 
each script is generated, the values of the appropriate flight parameters are included in the script’s code. After all of 
the scripts are generated, the attitude of the modeled GLAST satellite is then defined within the COTS analysis 
software as a series of time-ordered attitude profile segments. During each segment, the attitude of the modeled 
satellite is defined using the aligned and constrained method. For each segment, the +z body -axis of the model is 
aligned with a vector defined by the appropriate plug-in script, and the +x bo d y -axis is constrained to the Sun vector. 
Using these techniques, the FDS creates a satellite model that dynamically responds to commands in the same way 
that GLAST does. The result is the ability to use satellite commands to create a predicted attitude profile that 
simulates the GLAST observatory. 


Table 1. Timetable of TDRS Scheduling 


llll 

pays 

Preliminary Science Timeline Received 

19 

TDRS Contact Request Generated and Sent to NCCDS 

18 

Final Science Timeline Received 

5 

Confirmed TDRS Contact Schedule Received 

3 

Final Contact Schedule Generated 

2 

Command Load Generated " • * - ■“* 

2 i__. 

Commands Uploaded Jo GLAST ’ 

1 

Uploaded Commands Go; Active, \. 

0 


V* TDRSS Contact Request Generation 

With GLAST’s orbit and attitude predicted for a future scheduling week, the next step is to produce an optimized 
TDRSS contact request to be sent to the NCCDS. The NCCDS deconflicts the GLAST contact request with similar 
contact requests from all other missions to determine a single, confirmed contact schedule for each TDRS. To 
produce GLAST’s TDRSS contact request, the FDS must account for all of GLAST’s scheduling constraints. The 
complexity of modeling each constraint is dependent on the inherent abilities of the COTS scheduling software. The 
COTS software allows a user to create tasks and resources and to define various attributes of each. Resources are 
created for objects which are necessary to support TDRS contacts, such as the GLAST Ku-band antenna and each of 
the schedulable TDRSs. A repeatable task representing TDRSS contacts is then created. This task is defined to 
require the use of the Ku-band antenna resource and one of the TDRS resources. Once the scheduling definition is 
complete, the COTS software uses a powerful constraint deconfliction and schedule optimization routine to produce 
an ideal solution. 

The COTS scheduling software’s task and resource attributes provide the user with many different tools that can 
be used creatively and in combination with one another to model a wide variety of constraints. In some cases, 
however, the supplied tools are not able to fully model GLAST’s scheduling constraints. In such cases, the custom 
software of the FDS performs some of the modeling outside of the COTS software in such a way that the results are 
compatible with its supplied tools. This allows the constraint modeling results to be introduced back into software so 
that all of the pertinent scheduling information is contained within COTS software. This allows the FDS to take full 
advantage of the software’s deconfliction and optimization algorithms to determine the optimized weekly TDRS 
contact requests. 

J. Constraints Modeled Within COTS Software 
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The following sections describe the GLAST scheduling constraints and their modeling within the COTS 
scheduling software. 

5. Line-of-sight & Schedulable Resources Constraints 

The most obvious scheduling constraint is that TDRS contacts can only be scheduled when the GLAST Ku-band 
antenna has line-of-sight-access to a schedulable TDRS. To apply this constraint in the COTS scheduling software it 
is necessary to determine the times when the modeled GLAST Ku-band antenna has access to each of the 
schedulable TDRSs. As noted above, the Ku-band antenna has an effective field-of-view of 2 tt steradians centered 
on the -z side of the observatory body reference frame. The antenna pointing mechanism can slew faster than the 
observatory. This permits an important assumption that throughout any attitude profile, the Ku-band antenna can 
follow a TDRS as long as the satellite remains within the antenna’s effective field-of-view. With this assumption in 
place, it is necessary to model only the effective field-of-view (using a simple conic sensor), eliminating the need to 
model the narrow-beam antenna and its pointing mechanism separately. To determine when the Ku-band antenna 
has line-of-sight access to each TDRS, the FDS instructs the COTS analysis software to generate an access report 
between the sensor and each schedulable TDRS. This data is used in the definition of the TDRS contact task of the 
COTS scheduling software to limit times when a TDRS contact can be scheduled. To instruct the software that there 
is a choice of TDRSs, the TDRS contact task definition resource attribute is set to require the GLAST Ku-band 
antenna and any of the schedulable TDRS resources. In other words, a TDRS contact cannot be scheduled unless the 
Ku-band antenna and the corresponding TDRS resource are simultaneously available. A table defining which 
TDRSs are schedulable is maintained in a configuration file that is read by the FDS at runtime. 

6. Singular Constraint 

GLAST can only have a contact with one TDRS at a time. This constraint is accounted for in the COTS software 
by setting the accommodation attribute of the GLAST Ku-band antenna resource to one. 

7. Solar RFI Constraint 

The GLAST RF link is susceptible to solar Radio Frequency Interference (RFI). Therefore, it is necessary to 
avoid scheduling contacts whenever a TDRS/GLAST RF link is within 5° of the Sun vector. For this constraint, the 
COTS Analysis software generates a report that provides the angle between the GLAST-to-TDRS vector nnd the 
GLAST-to-Sun vector for each schedulable TDRS over the scheduling period. This report is ingested^by the 
scheduling software and is used to constrain the schedulable TDRS contact time. Scheduling is prevented when the 
angle is less than 5° or greater than 175°. The configurable solar RFI angle is maintained in a configinationffile that 
is read by the FDS at runtime. ^ \ 

8. Atmospheric RFI Constraint •••; .. <• 1 • ; < 

The GLAST RF link is also susceptible to atmospheric RFI. As a result, TDRS contacts must be avoided when 
the RF link is within 3.1° of the Earth limb. This constraint is applied within the COTS analysis software and passed 
to the COTS scheduling software. The COTS analysis software allows the user to define an Earth grazing angle 
constraint. This constraint is applied naturally when the analysis software computes the TDRS view period reports. 
The view periods include only those times when the RF link is outside of the grazing angle. The configurable 
grazing angle is maintained in a configuration file that is read by the FDS at runtime. 

9. Maximizing Contact Duration 

Longer contacts are preferable to shorter ones. It is therefore necessary to configure the COTS software to 
maximize the duration of scheduled contacts so that the entire view period is used. This is done simply by 
configuring an attribute of the TDRS contact task to maximize the task’ s duration. 

10. Preference for Longer Duration Contacts 

The durations of the maximized contacts will vary. It is desirable to bias the COTS scheduling software to prefer 
scheduling contacts with longer durations over contacts with shorter ones. The scheduling software has a 
configurable figure of merit calculation whereby the user can set the weighting of various attributes of a deeonflicted 
schedule. Once the deconfliction algorithm has produced a family of solutions, the figure of merit calculation is 
applied to each. The solution with the highest figure of merit score is selected as the best. The figure of merit 
calculation has an attribute for weighting the importance of the contact task’s duration. To satisfy the constraint, the 
weighting for this attribute is simply set to a relatively higher value than the weighting for other, less important 
solution attributes. 

11. Minimum Contact Duration Constraint 

Science downlink contacts less than 5 minutes in duration are not long enough to warrant scheduling. This 
constraint is directly applied in the scheduling software as the minimum duration attribute of the TDRS contact task. 
The configurable minimum contact duration is maintained in a configuration file that is read by the FDS at runtime. 
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12. Maximum Contact Duration Constraint 

In Inertial Point mode, the duration of a TDRS view period can vary from zero to over 59 minutes. During long 
contacts, the SSR would likely downlink all of its stored science data. Any remaining pass time would be spent 
downlinking real-time housekeeping data. This potential inefficiency is reduced by capping contact durations at a 
user-configurable maximum amount of minu tes. This constraint is directly applied in the scheduling software as the 
maximum duration attribute of the TDRS contact task. The maximum contact duration is set to be just larger than 
the maximum expected view period duration in Sky survey mode. The configurable maximum contact duration is 
maintained in a configuration file that is read by the FDS at runtime. 

13. Optional TUT Constraint 

The normal method of scheduling TDRS contacts is to begin the process several weeks in advance, during what 
is known as the forecast scheduling period. During this time, the NCCDS weighs the needs and priorities of all 
supported missions to determine the confirmed contact schedule. This process normally leaves some TDRS services 
unclaimed by any customers. This time is known as TDRS Unscheduled Time (TUT). TUT is available for missions 
to use on a first-come-first-serve basis and may be secured minutes before acquisition of signal. Although not a part 
of the normal scheduling process, it is advantageous for the GLAST MOC to have an optional ability to schedule a 
TUT contact as necessary when the attitude permits. The FDS has a mode of operation that retrieves a TUT report 
from the NCCDS TUT server via the internet. When in this mode, the FDS adds a TUT resource for each 
schedulable TDRS in the COTS scheduling software. The TDRS contact task is revised to require the use of the 
appropriate TUT resource, in addition to the corresponding TDRS resources and the GLAST Ku-antenna resources. 
The FDS then uses the TUT report to define times when the TUT resource is available to be used. This effectively 
constrains the COTS scheduling algorithm to be able to schedule contacts only during a TUT period. 

K. Constraints Modeled External to COTS Software 

If the COTS scheduling software is unable to model a particular constraint, then the custom software of the FDS 
must be used instead. When the constraint calculations are done outside of the COTS software, their results are 
reintroduced into the COTS software. This allows the COTS software to have all of the necessary constraint 
information defined within it. The FDS can thus rely on the . full powers of the deconfliction and optimization 
routines of the COTS software.. The following sections describe the techniques used to model GLAST scheduling 
constraints outside of the COTS software. . . v ' . V. — .’ V ' 

14. Timeslot Boundary Constraint 

Inevitable inaccuracies in the predicted orbit and attitude are most likely to impact the accuracy of the beginning 
or ending times of a TDRS view period. It is, therefore, beneficial to avoid scheduling contacts to start at the very 
beginning or stop and the very end of a view period, wherever the margin exists to do so. Most contacts, especially 
those executed while in Sky Survey mode, are shorter than the maximum contact duration. For these, there is no 
better choice than to schedule the entire view period. However, during longer view periods (such as those routinely 
encountered while in Inertial Point mode) the potential time spans are much longer than the maximum contact 
duration. In these cases, the COTS scheduling algorithm has a natural tendency to schedule a contact as early as 
possible, at the beginning of the view period. To prevent this, a simple algorithm is used to make the GLAST 
resource unavailable at select times. To apply this algorithm, the FDS first elicits a report from the scheduling 
software that contains the timeslots for the TDRS contact task. Timeslots are constraint-free windows of time during 
which a task may be scheduled. They are comprised of the overlap of each required resource’s availability times and 
the GLAST-to-TDRS view period times 4 . For each timeslot that is greater than maximum contact duration, the 
algorithm computes resource blackout times. The blackout times are simply the difference between the timeslot 
duration and the maximum contact time duration divided fry two and are applied to each end of the timeslot. This 
forces a maximum duration contact to be centered within its timeslot. During very long timeslots, it is advantageous 
to prevent too much of the timeslot from being blacked out. For this reason, the maximum blackout time is capped at 
a user-configurable value (approximately one minute). The configurable maximum blackout time is retained within 
a configuration file that is read by the FDS at runtime. 

15. Contact Time Targeting 

Two highly-coupled, GLAST-unique constraints that must be modeled outside of the COTS software are 1) 
the FDS must schedule a user-selectable amount of total TDRS contact time per day, and 2) TDRS contacts must be 
spaced evenly throughout the day. Since the maximized contacts have variable duration, an exact amount of contact 
time per day is not normally achievable without artificially shortening the durations of some of the contacts. 
Shortening contacts conflicts with the Maximize Contact Duration constraint. To balance these seemingly 
conflicting constraints, the custom code of the FDS uses an algorithm designed to schedule a targeted number of 
contact minutes per day rather than schedule an exact number of contact minutes per day. The algorithm assumes 
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that the variance in the mean view period duration and gaps in schedulable view periods are both relatively small. 
With the maximum contact duration set within the COTS software to be approximately equal to the maximum 
expected view period duration in Sky Survey mode, these assumptions become true in either science gathering 
mode. Using the reported TDRS task timeslots, the algorithm first computes the mean usable timeslot duration. For 
this calculation, timeslots that are less than the minimum contact duration are excluded, and timeslots that are 
greater than the maximum contact duration are counted as having only the maximum duration. Next, a task repeat 
period is calculated by taking the integer of 1440 minutes divided by the mean usable timeslot duration multiplied 
by the targeted contact minutes per day. The COTS scheduling tool has task attributes that allow the user to define 
the frequency with which a task is repeatedly scheduled and the minimum time between consecutive tasks. The FDS 
sets the tasks repeating frequency to schedule a contact once every task repeat period. This effectively divides each 
scheduling day into a series of segments such that if one contact is scheduled during each segment and each contact 
duration is equal to the mean contact duration, then the proper number of minutes per day will be achieved. Next, 
the FDS sets the minimum time between consecutive tasks attribute to half of the calculated task repeat period. This 
prevents consecutive contacts from being scheduled too closely together, by the first being scheduled close to the 
end of one day segment and the second being scheduled close to the beginning of the next segment. By applying this 
algorithm, the FDS automatically adjusts the task attributes in response to the attitude-driven view periods to 
produce a set of constraints that will target a specific number of minutes of contact time per day and space them 
evenly throughout the scheduling period. 



Figure V-l Screenshot of GLAST Flight Dynamics System 

L. Specification of Target Contact Time _ 

With a method to target a specific amount of contact time in place, some thought must be put into determining 
the amount of time that should be targeted. 56 minutes of TDRSS downlink time per day is required to match the 
average daily data load in the SSR. The SSR has a storage capability large enough to accommodate sizable gaps in 
consecutive science downlink contacts. The 56 minute figure then represents the minimum amount of time 
necessary to ensure that no data is lost. There are two factors that require the scheduled TDRS contact time to be 
significantly larger than this minimum. First, as a part of routine operations, the pre-planned science-driven attitude 
profile will be altered as a result of ToOs and ARs. These events occur with little or no prior warning. Altering the 
attitude will have unpredictable effects on previously-calculated TDRS view periods. As a result, it is expected that 
some confirmed TDRS contacts will be routinely missed. Second, there is no guarantee that all of the requested 
TDRSS contacts will be granted. Because the attitude-driven view periods and scheduling constraints are highly 
restricted, GLAST has very little flexibility in the times that contacts can be scheduled. This reduces the ability of 
the NCCDS to deconflict GLAST’s scheduling needs with other missions vying for the same resources. Therefore, it 
is entirely probable that the NCCDS will not be able to accommodate some of GLAST’s contact requests. 
Combating these two effects is simply a matter of requesting extra TDRS contacts. Any contact requests that are not 
granted and any confirmed contacts that are missed due to ARs and ToO are compensated for by these extra 
contacts. Determining the necessary amount of extra contact time required is not a trivial matter. TDRS resource 
loading studies as well as predictions of AR and ToO frequencies and durations are in progress. The results of these 
analyses will yield optimum target contact times for a variety of conditions. It is expected that the optimum target 
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contact time will routinely vary in response to changing external conditions. For this reason, the target contact time 
is the sole adjustable constraint parameter that is not held in a configuration file. Rather, the user is required to 
specify the target contact time each time the FDS is run in this mode. 

M. Schedule Deconfliction and Optimization 

With all of the above constraints successfully modeled in the COTS software, the scheduler’s deconfliction and 
optimization routine is executed to determine an optimized solution. In doing so, the COTS scheduling software 
uses a sophisticated algorithm to assign contacts to timeslots within the boundaries of the defined constraints to 
produce a schedule solution. This is done repeatedly, applying the constraints in a different order each time. The 
result is a family of deeonfiicted solutions. To determine the best solution, the COTS software applies a figure of 
merit calculation to each. The solution with the highest figure of merit score is selected as the optimum solution. 4 
Since the assigned contact times are likely to differ from the mean usable timeslot duration, and timeslots are not 
always available uniformly throughout the day, the FDS is only able to schedule approximately the targeted number 
of minutes of contact per day. If the average contact time per day of the optimized solution is greater than the 
targeted value, then the FDS considers the solution adequate. If that is not the case, then the FDS applies an iterative 
approach to increase the average scheduled contact time. This is done by reapplying the time targeting algorithm 
with a decreased task separation period. This causes the scheduling software to schedule tasks closer together, which 
allows more tasks to be scheduled during the scheduling period, thus increasing the average contact time per day. 
This process is repeated until the targeted contact time is met or exceeded or until the separation period has changed 
from the original by a configurable percentage value. The latter condition is encountered only under highly unusual 
conditions. In this unlikely case, the FDS pauses execution to allow the user to use the COTS scheduling software 
GUI to manually assign task contact times. 

Once an optimized schedule solution with enough contact time is found, the FDS next uses output reports from 
the scheduling software to create several files that are used as input to the NCCDS SWSI system. One of these files 
contains all of the TDRS contact service requests, called Service Action Requests (SARs), for the scheduling week. 
A small, configurable temporal pad is added tp the beginning and end of each SAR making the requested contact 
time -longer than what is predicted to v be, possible .This is done To account for any orbit and attitude prediction 
inaccuracies.. Once per week, and 18 days prior to the GLAST scheduling week,, the necessary schedule request files 
are sent to the NCCDS using the. SWSI .system. . . _ , » . vV .v . * • : • w . 

. i v •' *, i i. ' . . V J ' r';. •->. V- ‘Li- r.v- . ; - 

N. TUT Scheduling . Vr . 

It is possible, but not probable, that conditions may result* where there is not enough scheduled TDRS contact 
time to downlink all of the necessary science data. This may result from not requesting enough TDRS contacts, from 
not getting enough contact requests confirmed, or from having an unusually large number of confirmed contacts 
missed as a result of ToOs, ARs, or anomalous events. To alleviate the risk of losing data, the FDS has the ability to 
determine times when the TUT overlaps with the TDRSS view periods. A TDRS contact can be manually scheduled 
during a TUT period shortly before acquisition of signal. By running the FDS in the TUT scheduling mode, the 
attitude predictions will include attitude changes that result from ToOs and ARs. It is not possible to predict either 
the conditions driving the need for TUT scheduling or the path necessary to recover from this condition. Therefore, 
in this mode of operation, automated deconfliction and optimization is not performed. Instead, the FDS generates a 
report of all possible TUT contacts. It is then the responsibility of the flight operations team to determine which and 
how many contacts should be manually scheduled. 


VI. Final Contact Schedule Determination 

O. Need for Final Contact Schedule 

Two days prior to the GLAST command load, a final contact schedule must be created. The times from the final 
contact schedule are used by various components, both internal and external to the MOC, to coordinate TDRS 
science downlink and data processing activities. There are three scenarios that cause the final contact schedule to be 
different from the requested contact schedule. First, the NCCDS by this time has returned the confirmed contact 
schedule. It is likely that it will not include all of the contacts that were requested. Secondly, the GLAST science 
center has the right to revise the preliminary bus pointing commands so long as they do not interfere with the 
requested TDRS contacts. By this time also, the GLAST science center has delivered the final timeline of bus 
pointing commands. It must be confirmed that the contacts can still be supported with the revised attitude. Third, 
since the available GPS data is now much closer to the week of the actual contacts, the FDS is able to produce a 
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new, more accurate ephemeris. TMs places the satellite in a slightly different position and, consequently, a slightly 
new attitude. To rectify the situation, all of the newly available inputs are again run through FDS with a slightly 
different work flow. 

P. Final Schedule Determination 

In the first step of the final contact schedule determination, the orbit determination and attitude modeling are 
again performed in an identical manner as before using the revised inputs. From this, updated attitude-dependent 
TDRS view period reports are generated. These reports are used as scheduling constraints in the COTS scheduling 
software just as before. 

The difference is in the definition of the TDRS contact tasks within the COTS software. During the generation of 
the request schedule, a single TDRS contact request task is created. It is then defined to be scheduled repeatedly at 
the calculated frequency. The task is also defined to have a choice of using any of the schedulable TDRS resources. 
When generating the final contact schedule, task definition is much different. The FDS reads fixe confirmed TDRS 
contact schedule provided by the NCCDS. It then creates one TDRS contact task for each confirmed contact. Each 
task is restricted to use only the GLAST Ku-antenna and the TDRS that corresponds to the scheduled contact. 
Restrictions are also placed on the time when task can be scheduled. These times are set to match the corresponding 
time from the confirmed schedule. With this set-up, the COTS scheduling algorithm is again used to freely find an 
optimum schedule. However, since each task is so restricted, the scheduling algorithm can only assign contacts to 
times within the confirmed contact schedule window that overlap with the updated TDRS view periods. Since the 
original requested contact times include temporal padding at the beginning and end of the predicted view period, the 
confirmed contact time should be equally inflated. This ensures that any changes in the view period times resulting 
from orbit prediction updates will still fall within the confirmed contact times. 

Once optimization is complete, the resulting schedule represents the best prediction of the contact times. The 
FDS uses reports from the scheduling software to create reports that are used by various systems, primarily the 
command load generator, to coordinate the contacts. 

Vile Conclusions 

Q. Summary of the FDS 

The GLAST mission has complex scheduling requirements that must be met to ensure that all science and. 
housekeeping data is successfully recovered from the satellite. The placement of the Ku-band antenna on the 
satellite #nd the immovable attitude profile limits the times when TDRS contacts are possible. This requires the 
attitude of the satellite to be modeled so that TDRS view period predictions can be made. Since the view periods are 
relatively short in duration and they need to be scheduled 18-24 days in advance, it is important not only to 
accurately predict the observatory attitude, but also its position in orbit. Filtering and smoothing must be performed 
to improve the downlinked GPS solution to achieve the required orbit determination and propagation accuracy. In 
addition, GLAST has many contact scheduling constraints that must be deconflicted to produce the request for an 
optimum contact schedule. 

To solve these problems, the FDS is built upon the capabilities of a commercially available analysis software 
package. Wherever possible, the powers of the COTS software are harnessed to perform the majority of the 
computational duties. This approach greatly reduces developmental risk, time, and cost. However, because many of 
the functions that are required of the FDS are unique to the GLAST mission, the COTS software, by itself, does not 
have the capabilities to adequately perform them. In these cases, custom code is used to perform these functions in 
such a way that they integrate with the inherent capabilities of the COTS software. The ability to integrate custom 
code with the COTS software provides unlimited flexibility to meet mission-specific needs. In the case of the 
attitude modeling, the use of custom code allows the same algorithms that are used in the flight software to be used 
to orient the pointing axis of the modeled satellite. The inherent capabilities of the COTS software are then used to 
complete the attitude definition. This type of cooperation between custom and COTS software is prevalent 
throughout the FDS not only in the area attitude modeling, but also in orbit determination and constraint modeling. 
What results is an automated contact scheduling system, tailored to mission-specific needs, that ingests TDRS 
ephemerides, GLAST GPS position data, and bus pointing commands to predictively model the orbit and attitude 
and produce an optimized, conflict-free TDRS contact schedule. 

Ro Applications to Future Missions 

Although the FDS is designed to meet the specific scheduling needs of the GLAST mission, the approaches and 
techniques used have potential application to a wide-range of scheduling needs for future missions. In addition, 
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because the custom code interacts with the provided tools of the COTS software, it is by nature highly modular. This 
makes the system easily adaptable to other missions with similar needs. For instance, two custom developed scripts 
control the two science gathering attitude modes. These can easily be replaced by alternate scripts that model the 
unique attitudes of other satellites. Alternately, the attitude modeling can easily be omitted for missions that do not 
have an attitude dependency but still have complex scheduling constraints and a need for automation. Likewise, the 
FDS only schedules contacts for TDRS. This is controlled by the contact task definition. The definition can be easily 
revised to use ground stations, sea or airborne stations, other satellite communication systems, or any combination of 
the prior. The same is true of the schedule constraint modeling. Scheduling constraints are often highly unique to a 
specific scheduling problem. The COTS scheduling software provides a wide variety of generically applied tools 
that can be used alone or in combination to model many different types of constraints. Wherever the provided tools 
prove inadequate, custom code can be used to augment the provided capabilities. The scheduling constraints detailed 
in this document are only representative of what is possible. Whereas many of the constraints are unique to the 
GLAST mission, the approaches and techniques can be applied to other missions. Finally, with all of the 
constraining scheduling mformation properly defined within the COTS package, the COTS scheduling and 
optimization algorithm is universal and can be used to find an optimum solution to any scheduling problem. 
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